\chapter[ooa]{Objektový návrh pro Matlab}
Kapitola se zabývá návrhem obecného Shopu - nového objektu, který
by měl vzniknout v~TORSCHE Scheduling toolboxu. Nejprve budou zmíněny
požadavky, které jsou kladeny na tento objekt. Poté bude čtenář
obeznámen se samotným designem.

\section{Požadavky na Shop}
Přidávání nových objektů a nových funkčností do už vyvinutých aplikací (případně do aplikací, které jsou už delší dobu vyvíjeny
		a nejsou doposud úplně hotovy) je vždy trochu oříšek.
Návrhář musí brát ohled na to, aby nedošlo k~situaci, kdy se některé
objekty budou překrývat - bude docházet k~redundanci. Nepříjemná je také
situace, kdy se pokusí o~zcelení původních objektů s~novými, které vede
k~velmi složitým vztahům mezi objekty a tím se pak zvyšuje riziko chyby
(špatného návrhu). O~to horší má pak situaci další návrhář, který
přidává další objekt do už tak složitého systému.

Cílem je tedy kompromis mezi všemi kritérii.




Požadavky na objekt Shop jsme získali shrnutím informací z~literatury
\cite[Blazewicz,ComplexScheduling,Pinedo-theory,Pinedo-planningAndScheduling,CBS], kde jsme se setkávali s~níže uvedenými pojmy, které rozšiřují teorii v~kapitole \in[uvod_rozvrhovani] a zejména v~části \in[rozvrhovani-shopy].


{\it Positive and negative time lags} (časová okna, zobecněné relace
		následnosti) jsou zmiňovány prakticky u~všech autorů.
Jedná se o~časové vztahy mezi jednotlivými úlohami určující dobu mezi
začátky úloh podle vztahu \in[eq:timeLags].
\placeformula[eq:timeLags]
\startformula
s_A + d_{AB} \leq s_B
\stopformula
$d_{AB}$ značí časové okno mezi úlohami $A$ a $B$. Tato doba může být obecně i
záporná vše zobrazuje obrázek \in[fig:timeLags]. 
\placefigure
  [here,force]
  [fig:timeLags]
  {Dvě možnosti velikosti časového okna. Z~obrázků je zřejmé, proč se
	  časovému oknu také říká zobecněná relace následnosti.}
{\startcombination[2*1]
    {\externalfigure[images/positiveTimeLags]}   {Kladné časové okno.}
    {\externalfigure[images/negativeTimeLags]} {Záporné časové okno.}
  \stopcombination
}
Stejně často se setkáváme i s~{\it batch processing} -- joby se
seskupují do {\it dávek} a ty jsou pak plánovány jako rozvrhovací jednotky.



Další poznatky směřovaly většinou do oblasti zdrojů --
	\cite[ComplexScheduling] se zmiňuje například o~zdrojích s~kapacitou $n$ (může být využíván v~jeden okamžik až $n$ úlohami), obnovitelnosti zdrojů (dostupnost zdroje je funkcí času a závisí na jeho předchozí vytíženosti; zdroje mohou být úplně neobnovitelné, anebo částečně obnovitelné v~jistých časových okamžicích) a
 jejich různých režimech (výkon zdroje je funkcí času\footnote{Je-li zdroj člověk, pak mívá po obědě menší pracovní výkonnost než poránu, když přijde do práce.}).

 V~\cite[Pinedo-theory, ComplexScheduling] se setkáváme s~pojmy {\it transport robots} (transportní roboti) a {\it limited buffers} (mezisklady s~omezenou kapacitou).

Transportní roboti se vyskytují tam, kde je  nezanedbatelná doba mezi
koncem úlohy na jednom stroji a začátkem úlohy na jiném. Po tuto dobu
právě robot přenáší výrobek mezi jednotlivými stroji. Setkáváme se
s~dvěmi situacemi, které mohou nastat:
\startitemize
	\item Neomezený počet robotů: Každý job má alespoň jednoho
	robota\footnote{Má-li jich přidělených více, pak jsou
		přebyteční; Pokud rozvineme pojem \quotation{robot} i
			na člověka, pak si pod tím můžeme představit
			několik kopáčů sledujících jednoho kopáče, který
	občas kope.}. Tím pádem není problém s~konflikty mezi joby
	transportní čas se modeluje jako time lag.
	\item Omezený počet robotů: Je méně robotů než je jobů. Pak se
	roboti modelují jako stroje s~kapacitou 1.
\stopitemize

Mezisklady s~omezenou kapacitou budou ukázány na příkladu:

Mějme množinu jobů sestávajících se z~několika úloh. Může nastat
situace, kdy jedna úloha z~jobu $J_i$ je dokončena v~čase $t_0$ na
stroji $\mu_a$. Job $J_i$ má pokračovat další úlohou, která má být
vykonávána na stroji $\mu_b$. Shodou okolností je zrovna stroj $\mu_b$
vytížen až do času $t_1$. Tím pádem po dobu $\Delta t= t_1-t_0$ blokuje
z~jobu $J_i$ stroj $\mu_a$ a žádná jiná úloha na něm běžet nemůže. 

Proto se zavádějí mezisklady, kam se tyto úlohy odloží a neblokují stroj. Pokud už je mezisklad plný,
     nezbývá než čekat na uvolnění dalších strojů, aby se mezisklad
     uvolnil.

Existuje několik modelů meziskladů.
\startitemize
	\item {\it General}: existuje $n$ \quotation{centrálních}
	meziskladů, které využívají všechny úlohy.
	\item {\it Job-dependent}: Každý job má svůj mezisklad.
	\item {\it Pairwise}: tento model svazuje stroje do dvojic a
	každé dvojici přiřazuje mezisklad.
	\item {\it Input}: na vstupu každého stroje je mezisklad velikosti
	$n$.
	\item {\it Output}: na výstupu každého stroje je mezisklad
	velikosti $n$.
\stopitemize

V~\cite[Pinedo-planningAndScheduling] se dočteme o~paralelních
strojích pro Job-shop a Flow-shop. Ty pak mají přízvisko {\it flexible}.
A~dále také o~tzv. {\it supply-chain} -- množina shopů je svázána do sítě
s~určitými precedenčními vazbami. 

	Souhrnem  a kompromisem mezi vším výše zmíněným a dalšími našimi nápady je tento seznam požadavků na objekt Shop:

\startitemize
	\item Různé délky jobů -- joby mohou obsahovat proměnný počet
	úloh.
	\item Zdroje s~kapacitou $>1$.
	\item Alternativní zdroje -- uživatel bude mít možnost
	nadefinovat si pro danou úlohu více zdrojů, na kterých může být
	provedena.
	\item Paralelní zpracovávání úlohy na více strojích.
	\item Zobecněné relace následnosti
	\item Transportní roboti
	\item Mezisklady s~omezenou kapacitou.
\stopitemize

\section{Návrh objektu Shop}
Při vlastním návrhu jsme vycházeli z~poznatků a požadavků v~předchozí
části. 

Různé délky jednotlivých jobů jsme vyřešili použitím struktury TaskSet. Tím pádem je vstupem objektu Shop cell struktura,
       	která obsahuje $n$ TaskSetů odpovídajících $n$ jobům. 
Tento přístup navíc vede k~dobrému zakomponování objektu Shop do
struktury  celého toolboxu -- TaskSet je totiž jedním z~jeho pilířů.

Paralelní a alternativní zdroje se realizují přímo na úrovni objektu
Task, který obsahuje proměnnou processor (matice). Hodnoty v~prvním
řádku matice určují alternativní zdroje; má-li matice více řádků, pak sloupce odpovídají množině zdrojů, 
	které mohou úlohu paralelně vykonávat.  Vše je na níže uvedeném příkladu (paralelní zpracovávání ještě nejsou v~současné verzi Tasku k~dispozici, proto není uvedený celý výstup, ale pouze předpokládané volání funkce).
\startcode
>> t=task(1) % vytvoření úlohy 
Task ""
 Processing time: 1
 Release time:    0
>> t.Processor=[1 3]  % Úloha může být vykonána na stroji 1 nebo 3
Task ""
 Processing time: 1
 Release time:    0
 Processor:       1  3
>> t.ProcTime=[2 3]  %Na stroji 1 resp. 3 bude trvat vykonávání 2 resp. 3 jednotky času
Task ""
 Processing time: 2  3
 Release time:    0
 Processor:       1  3
>> t.Processor=[2 4;3 3] % Úloha může být vykonána na stroji 2 a zároveň 3 nebo 4 a zároveň 3. 
\stopcode


Zdroje s~kapacitou vyšší než 1 se budou vkládat jako parametr algoritmu
řešícího rozvrhovací problém.


Zobecněné relace následnosti rozšíří objekt TaskSet a bude se zadávat do TSUserParam (nepovinný uživatelsky definovaný parametr). Tento parametr se bude zadávat pomocí matice, kde se nadefinují časové intervaly mezi jednotlivými úlohami.

Transportní roboti a mezisklady s~omezenou kapacitou tvoří na jednu stranu jednotnou a
ucelenou oblast problémů, ale na druhou stranu není jejich četnost
výskytu tak vysoká. Hlavně proto jsme vytvořili objekty (obsahující
		všechny zmíněné) modely pro obě
kategorie problémů, ale umístili jsme je do UserParams objektu shop
(nepovinné parametry).

Vše přesně zobrazuje obrázek \in[fig:ooa_UML]. Celé UML je v~příloze
\in[uml_full].

\placefigure[here,force][fig:ooa_UML]{UML class diagram general shopu v~TORSCHE
	Scheduling toolboxu}
{\externalfigure[images/shop][width=1\makeupwidth]}


